Skip to content

fix(linear): keep connection through transient check failures#1868

Open
janburzinski wants to merge 4 commits intogeneralaction:mainfrom
janburzinski:emdash/linear-always-unconnecting-z5bjx
Open

fix(linear): keep connection through transient check failures#1868
janburzinski wants to merge 4 commits intogeneralaction:mainfrom
janburzinski:emdash/linear-always-unconnecting-z5bjx

Conversation

@janburzinski
Copy link
Copy Markdown
Collaborator

summary

linear connection auth error and timeout was being handled the same this would cause a disconnect just because i lost internet

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 4, 2026

Greptile Summary

This PR fixes a regression where transient network failures (e.g., losing internet) were treated identically to auth errors, causing Linear to disconnect unnecessarily. The fix introduces a null-sentinel lastVerifiedDisplayName field and an isAuthFailure helper to distinguish permanent auth errors from transient ones — keeping the connection alive through temporary failures.

  • P1 regression in fetchViewerDisplayName: The original code used org?.name (optional chaining) but the extracted helper uses organization.name — if viewer.organization resolves to null, this throws a TypeError that would cause saveToken to reject a valid token with an obscure error.

Confidence Score: 4/5

Safe to merge after fixing the dropped optional chaining on organization?.name.

One P1 regression: the extracted fetchViewerDisplayName helper dropped the original org?.name optional chaining, which could throw a TypeError if viewer.organization resolves to null — causing saveToken to reject a valid token. No P0 issues; the core transient-failure logic is sound.

src/main/core/linear/linear-connection-service.ts — specifically line 124 in fetchViewerDisplayName

Important Files Changed

Filename Overview
src/main/core/linear/linear-connection-service.ts Correctly distinguishes transient failures from auth errors using null sentinel for lastVerifiedDisplayName; fetchViewerDisplayName helper drops the original optional chaining (org?.nameorganization.name), which could throw if viewer.organization resolves to null.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[checkConnection called] --> B[getStoredToken]
    B -->|no token| C[lastVerifiedDisplayName = null\nreturn connected: false]
    B -->|token found| D[fetchViewerDisplayName]
    D -->|success| E[lastVerifiedDisplayName = displayName\nreturn connected: true]
    D -->|throws| F{isAuthFailure?}
    F -->|yes| G[lastVerifiedDisplayName = null\nreturn connected: false + error]
    F -->|no transient error| H{lastVerifiedDisplayName === null?}
    H -->|yes never verified| I[return connected: false]
    H -->|no was previously verified| J[log.warn\nreturn connected: true\ndisplayName: lastVerifiedDisplayName]
Loading
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/main/core/linear/linear-connection-service.ts:124
The original call sites used `org?.name` (optional chaining), but the extracted helper removed it. If `viewer.organization` ever resolves to `null` or `undefined`, `organization.name` will throw a `TypeError`. In `saveToken` this would cause a valid token to be rejected with an obscure error message; in `checkConnection` it would be treated as a transient failure. Adding `?.` restores the original defensive behaviour.

```suggestion
    return organization?.name ?? viewer.displayName ?? undefined;
```

Reviews (2): Last reviewed commit: "fix(linear): handle verified connections..." | Re-trigger Greptile

Comment thread src/main/core/linear/linear-connection-service.ts Outdated
Comment thread src/main/core/linear/linear-connection-service.ts Outdated
Comment thread src/main/core/linear/linear-connection-service.ts Outdated
Comment thread src/main/core/linear/linear-connection-service.ts Outdated
@janburzinski
Copy link
Copy Markdown
Collaborator Author

@greptile review

const client = this.getClientForToken(token);
const viewer = await client.viewer;
const organization = await viewer.organization;
return organization.name ?? viewer.displayName ?? undefined;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 The original call sites used org?.name (optional chaining), but the extracted helper removed it. If viewer.organization ever resolves to null or undefined, organization.name will throw a TypeError. In saveToken this would cause a valid token to be rejected with an obscure error message; in checkConnection it would be treated as a transient failure. Adding ?. restores the original defensive behaviour.

Suggested change
return organization.name ?? viewer.displayName ?? undefined;
return organization?.name ?? viewer.displayName ?? undefined;
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/main/core/linear/linear-connection-service.ts
Line: 124

Comment:
The original call sites used `org?.name` (optional chaining), but the extracted helper removed it. If `viewer.organization` ever resolves to `null` or `undefined`, `organization.name` will throw a `TypeError`. In `saveToken` this would cause a valid token to be rejected with an obscure error message; in `checkConnection` it would be treated as a transient failure. Adding `?.` restores the original defensive behaviour.

```suggestion
    return organization?.name ?? viewer.displayName ?? undefined;
```

How can I resolve this? If you propose a fix, please make it concise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant